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Abstract 

This  paper  presents  an  analysis  of  what  it  means  for  an  enterprise  to  be  integrated,  what  enterprises  are 
really  trying  to  achieve  by  integrating  their  processes,  what  is  really  going  on  among  their  processes,  and 
how  integration  may,  or  may  not,  change  that.  Some  approaches  to  analyzing  enterprise  operation  are 
discussed. 

With  an  idea  about  how  an  enterprise  really  operates,  the  paper  proposes  a standards-making  philosophy 
that  will  improve  enterprise  operations.  The  purpose  is  to  create  a standardization  strategy  for  integration 
that  matches  the  operating  enterprise.  If  that  is  not  done,  the  effort  to  produce  the  standards  largely  will  be 
wasted.  This  is  because  an  ill-conceived  standards  strategy  will  not  alter  the  way  enterprises  actually 
operate  at  the  activity  level.  Finally,  there  is  a suggestion  that,  perhaps,  enterprise-integration-related 
standards  are  in  a category  different  from  the  usual  standards  for  hardware,  software,  and  protocols. 
Because  these  standards  affect  the  entire  enterprise,  and  even  interacting  enterprises,  they  are  more  in  the 
category  of  horizontal  standards  such  as  quality  and  environmental  standards. 

Key  words:  Enterprise  integration,  information  technology,  standards,  strategic-standardization 
management,  horizontal  standards. 

1.  Integrating  Enterprises 

Enterprise  integration  is  an  improvement  concept,  as  are  total  quality  and  error-free  performance.  These 
concepts  have  proven  to  be  very  difficult  to  implement  successfully  because  the  desired  degree  of 
improvement  is  difficult  to  achieve.  One  part  of  the  difficulty  lies  in  the  sheer  complexity  of  changing 
almost  every  sector  of  the  business  to  achieve  whatever  goal  is  set.  Another  part  of  the  difficulty  is  in 
assigning  metrics  to  measure  progress.  Still  another  part  is  due  to  the  fact  that  these  concepts  do  not  refer  to 
singularities.  Any  evaluation  of  progress  is  only  a glimpse  or  a snapshot  in  a continuous  stream  of  mini- 
improvements that  happens  over  a period  of  many  years.  Management  has  been  trying  for  better  quality, 
higher  reliability,  and  better  communication  ever  since  there  has  been  business  for  profit.  There  is  always 
room  for  improvement  when  considering  quality,  reliability,  and  communication  among  engineering, 
manufacturing,  suppliers,  and  customers. 

Enterprise  integration  has  similar  characteristics.  Success  is  conditional  in  that  it  involves  technological 
improvement,  revising  some  principles,  and  the  presence  of  a compatible  infrastructure.  Enterprise 
integration  also  requires  a compatible  infrastructure  in  other  organizations,  so  that  the  objective  of  the 
investment  is  fully  utilized.  However,  two  businesses  probably  would  not  invest  in  synchronism,  for  many 
reasons.  If  compatible  infrastructure  does  not  exist,  the  investments  in  the  improvements  in  one  enterprise 
are  difficult  to  justify.  Also,  management  finds  that  it  is  very  difficult  to  translate  these  investments  into 
some  incremental  improvement  in  specific  business-improvement  strategies,  such  as  lower  product  cost, 
lower  cycle  time,  and  higher  quality. 
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On  the  other  hand,  some  businesses  have  invested  to  overcome  integration  barriers,  and  have  achieved  their 
integration,  cost,  and  quality  goals  and  there  was  enormous  improvement.  The  products  were  produced 
correctly,  the  first  time,  on  time,  but  at  such  a low  cost  that  the  facilities  and  people  that  were  required  in 
the  old  system  were  no  longer  cost  effective  and  justifiable.  Their  reaction  to  having  underutilized 
resources  was  not  positive.  The  solution  was  to  undo  the  improvement,  lose  a facility,  and  terminate 
people,  rather  than  change  old  attitudes  and  management  metrics!  In  these  situations,  applying  technology 
and  meeting  cost  and  quality  goals  are  necessary  but  not  sufficient  for  success  because  the  enterprise  could 
not  overcome  the  old  corporate  culture.  These  cultural  attitudes  must  be  kept  in  mind  when  analyzing  how 
enterprises  really  operate. 

Even  with  the  barriers,  there  exists  in  industry  an  eagerness  to  achieve  the  benefits  implied  by  the  words 
enterprise  integration,  but  with  a hesitancy  to  invest  in  it.  A lot  of  money  has  been  invested  in  the  past  with 
little  perceived  results.  But,  since  enterprise  integration  is  a continuum,  rather  than  a specific,  singular  goal, 
and  since  the  task  is  so  large  and  so  enterprise  wide,  the  incremental  improvements  that  have  been  made  are 
largely  unappreciated. 

In  a typical  scenario,  enterprises  evaluate  their  needs,  establish  their  character,  and  set  goals  to  achieve 
market  aspirations  at  an  executive-level  function  often  called  strategic  planning.  The  enterprise  is  a set  of 
processes  and  infrastructure  consisting  of  systems  that  employ  certain  technologies.  If  new  needs  and  goals 
require  new  or  upgraded  systems  or  processes,  and  if  there  is  a limited  amount  of  financial  means  to 
acquire  new  capability,  then  a trade-off  analysis  will  assign  priorities,  and  investments  will  be  made 
accordingly.  There  are  hundreds  of  choices  that  could  be  made.  If  we  multiply  this  one  scenario  by  all  of 
the  enterprises  that  are  making  the  same  kind  of  decision  there  is  a very  low  probability  that  any  two 
enterprises  will  have  invested  the  same  amounts  of  money  on  the  same  improvements  at  the  same  time. 
Their  infrastructure  improvements  and  process  improvements  will  evolve  at  different  rates.  Therefore,  what 
results  are  many  enterprises  with  sets  of  processes  and  infrastructure  that  are  not  interchangeable,  not 
interoperable,  or  at  the  same  level  of  process  granularity. 

This  is  also  true  of  organizational  functions  within  a single  enterprise  [NELL96].  Businesses  typically 
consist  of  groups,  divisions,  departments,  and  sections.  Somewhere  in  that  hierarchy  the  organization 
becomes  function  oriented  and  the  executive  establishes  incentives  to  subordinate  managers  to  reduce  the 
costs  of  their  function.  When  that  happens  there  is  no  advantage  to  doing  things  for  the  benefit  of  the 
enterprise  because  the  resulting  process  and  infrastructure  improvements  tend  to  suboptimize  and  even 
conflict  with  similar  investments  in  other  departments.  This  is  a cultural  problem  that  will  exist  whether  or 
not  there  are  standards  recommending  otherwise.  Enterprises  are  therefore  not  able  to  migrate  toward  one 
another.  The  fact  that  enterprises  or  processes  do  not  share  information  well  is  not  surprising. 

Enterprises  say  that  they  wish  to  be  integrated.  What  does  this  mean  really?  It  may  mean  to  an  enterprise 
that  has  tried  to  integrate,  that  management  is  disenchanted  with  the  integration  process  and  has  a greater 
reluctance  to  invest  in  integration  technologies.  Often,  managers  fail  to  see  in  the  above  scenario  that 
integration  is  neither  a one-time  activity,  nor  a singular  achievement,  nor  a final  state.  There  are  hundreds 
of  areas  to  change  that  will  achieve  an  improved  degree  of  integration,  and  there  is  not  enough  money  to  do 
it  all.  Even  if  the  money  were  there  and  the  investment  made,  there  would  be  a better  solution  shortly  after 
the  investment  because  technology  will  not  stop  advancing.  As  commerce  becomes  more  global,  and  there 
is  need  to  interact  with  offshore  partners  as  well  as  domestic  partners,  the  problem  compounds  because 
decisions  made  within  one  enterprise  often  do  not  coincide  with  the  decisions  made  in  other  enterprises. 

To  produce  an  output,  an  enterprise  or  a process  usually  needs  to  work  with  another  enterprise  or  process. 

To  work  with  can  mean  several  things.  Materials  and  tools  need  to  get  there.  Parts  and  components  need  to 
get  there.  Physical  things  need  to  exit.  Timing  is  important.  In  addition,  triggering,  instructions,  controls, 
intended  and  actual  output,  verification,  and  many  other  things  require  that  a significant  amount  of 
information  flows  into,  and  out  of,  the  process.  Here  is  where  the  going  becomes  difficult.  Judgement 
enters  the  process  and  the  possibility  of  misunderstanding,  or  miscommunicating,  is  possible.  In  fact, 
miscommunication  is  probable  and  to  establish  a smoothly  running  system  of  processes,  methods  to  resolve 
the  miscommunications  must  be  planned  into  enterprise  operation. 
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The  plan  to  resolve  the  miscommunications  can  take  several  tracks,  but  two  or  three  seem  to  predominate. 
The  first  has  to  do  with  changing  the  world  by  prescribing  that  all  of  the  hardware  and  software  shall  be 
from  the  same  manufacturer  to  prevent  miscommunications.  This  approach  rarely  works  because  the 
communications  come  from  people  in  the  enterprise,  not  from  the  hardware  and  software.  A related 
approach  is  to  force  all  of  the  possible  interactions  into  a predetermined  set  of  instructions,  queries,  and 
responses.  It  is  very  difficult  to,  a priori,  prescribe  all  the  possible  instructions,  queries,  and  responses.  As  a 
result  the  software  engineers  are  continuously  busy  adding  code  to  the  process  software  until  the  system  is 
too  ponderous  to  be  reasonably  productive.  Often  in  this  model  the  solutions  are  legislated,  in  effect,  by 
developing  top-down,  enterprise-specific  standards  that  must  be  uniformly  adapted  by  all  processes, 
planned  and  existing,  that  contribute  to  enterprise  output.  Everyone  must  be  on  the  same  version  of  the 
same  standard,  or  provide  some  kind  of  conversion  or  translators;  that  is,  insuring  forward  and  backward 
compatibility.  This  may  work  better  for  some  areas  of  the  information-technology  domain  than  in  other 
areas. 

Another  way  to  approach  this  problem  of  communication  is  to  analyze  how  communications  have  been 
handled  in  the  past,  before  computers,  and  realize  that  humans  negotiated  understanding  through  repeated 
questions  and  clarifications.  One  of  the  problems  in  the  enterprise- integration  domain  is  that  humans  and 
computers  must  interact  and  that  their  brains  think  differently.  So  far,  the  solution  has  been  to  make 
humans  interact  with  computer  systems  on  the  computer's  terms  rather  that  making  computers  interact  on 
human  terms.  People  really  need  smarter  computers  not  faster  ones.  On  a computer's  terms  all 
communication  must  be  in  precise  language  and  entered  through  the  human  machine  interface  without  a 
single  error.  Well,  humans  just  do  not  work  that  way.  Humans  tend  to  create,  tinker,  modify,  and  innovate— 
an  iterative  process  toward  some  goal. 

So,  using  the  humans-only  model,  what  must  happen  to  assure  proper  information  flow?  Proper 
information  has  been  flowing  between  processes  for  hundreds  of  years— or  else  manufacturing  enterprises 
would  have  produced  no  products.  Factory  communications  among  humans  will  involve  a minimum  of 
words  and  a lot  of  common-sense  information  that  is  taken  for  granted  in  human  discourse.  When  an 
engineer  hands  a drawing  of  a part  to  someone  in  operations  to  have  the  part  built,  the  drawing  contains 
s>Tnbols  referring  to  the  part,  but  the  amount  of  information  on  the  drawing  is  very  small  compared  to  the 
amount  of  information  that  is  transferred  (implied  and  inferred).  Most  of  the  information  transferred  is 
implicit  in  the  everyday  knowledge  that  humans  bring  to  bear.  This  is  in  addition  to  the  expertise  that  is 
shared  among  humans.  The  expertise,  acquired  from  formal  education  and  experience,  enables  the  human 
element  within  the  two  processes  to  imply  and  infer  what  they  need  from  the  information  that  is  contained 
in  the  symbols  on  the  drawing,  as  well  as  from  the  information  that  is  not  there. 

However,  in  the  human-driven  processes,  there  is  always  an  opportunity  for  additional  transfer  of 
information  that  completes  the  information  exchange.  This  is  the  information  in  the  oral  question-and- 
answer  negotiation  that  precedes  complete  understanding  during  the  inter-process  transfer.  When  a 
receiving  process,  such  as  an  operations  person,  completely  understands  the  concept  intended  by  a sending 
person,  such  as  a design  engineer,  a kind  of  process  integration  has  occurred.  This  integration  will  recur, 
one  process  at  a time,  through  the  product-life  history.  Enterprise  integrators  are  trying  to  use  information- 
technology  tools  to  improve  interprocess  interactions;  that  is,  make  the  information  interchange  repeatable, 
faster,  more  accurate,  and  computer  sensible.  Perhaps  there  is  a software  model  that  will  achieve  necessary 
integration,  improve  on  the  human  interactions,  but  not  require  a top-down  or  up-front,  complete,  and  error- 
free  definition  in  computer  terms. 

It  is  possible  to  achieve  lights-out  factories  and  totally  automatic  processes.  However  these  phenomena  are 
usually  an  extension  of  a human-driven  enterprise  someplace  and  are  a very  small  part  of  the  life  history  of 
a product.  Until  major  parts  of  a product-life  history  can  be  automated,  enterprises  and  a majority  of  the 
processes  will  act  largely  as  if  humans  were  communicating.  If  this  were  the  case  it  would  not  be 
productive  to  assume  the  enterprise  runs  as  if  it  were  totally  automated.  Negotiation  of  some  aspect  of 
inter-process  communications  will  be  the  rule  rather  than  the  exception.  With  the  enterprise  viewed  this 
way  it  may  be  more  useful  to  create  a strategy  for  a more  automated  enterprise  to  accommodate  this  reality, 
rather  than  to  assume  that  another  standards  model  is  better  because  it  reflects  the  way  analysts  wish  the 


enterprise  were.  The  necessary  interprocess  transactions  will  require  the  hardware  to  be  physically 
compatible,  the  software  to  interact  predictably,  the  communications  protocols  to  be  usable  jointly,  and  the 
information  to  be  mutually  understandable.  Achieving  this  will  require  a delicate  balance  of  human 
planning,  technology,  and  a properly  designed  standards  strategy.  There  also  will  have  to  be  a mechanism 
to  allow  an  enterprise  to  have  an  internally  designed  architecture  that  allows  the  processes  to  negotiate  the 
best  way  to  interoperate,  among  themselves,  in  a standard  way,  using  standard  infrastructure  elements. 

2 Standardization 

Having  determined  how  enterprises  will  operate  and  produce  an  output,  one  can  analyze  how  to  design  a 
system  of  realistic  standards  to  boost  process  interoperability  without  stifling  technology  development  and 
technology  insertion.  This  standards  view  will  involve  a standards  system  that  will  allow  enterprises  to 
operate,  change,  and  grow;  and  it  will  improve  operations  rather  than  hinder  them. 

To  determine  the  standards  that  are  necessary  depends  on  existing  technology  and  the  standards  that  are  in 
use  [NELL96].  The  analysis  will  be  aided  by  first  developing  a set  of  enterprise  models.  The  models  should 
show: 

• How  much  of  the  information  at  the  interfaces  between  applications  is  in  an  open  format 

• How  much  of  the  semantics  is  in  the  one-name-one-meaning  category 

• How  compatible  is  the  hardware 

• How  well  defined  are  the  software  interrelationships 

• Are  the  communication  protocols  agreed  upon 

• Is  there  a mutual  understanding  among  the  information  architectures  that  are  attempting  to 
communicate 

Even  with  all  of  that  defined,  the  business  rules  must  be  compatible,  government  regulations  for  commerce 
must  be  agreeable,  and  the  people  of  the  enterprise  must  truly  want  integration.  This  does  not  mean  to 
suggest  that  the  idea  of  a standard  enterprise  is  realistic.  Businesses  must  be  free  to  design  the  enterprise  of 
their  choice,  and  with  this  freedom  acceptable  integration  still  must  be  achievable. 

The  issue  of  what  things  should  be  standardized  and  what  should  be  good  software  design  is  difficult 
because  the  resolution  lies  in  a range  between  having  a few  low-level  standards  and  constraining  everything 
with  standards.  Often  the  easiest  and  least-effective  solution  to  a computer-compatibility  problem  is  to 
standardize  everything;  the  models,  the  modeling,  the  tools,  and  the  processes.  The  loss  of  user  delight,  the 
loss  of  opportunity  to  use  tools  especially  designed  for  the  job,  and  the  lost  opportunity  for  technological 
improvement  are  enormous.  It  would  stay  that  way  because  standards  always  seem  to  consume  more  time 
to  develop  than  does  the  technology  that  standards  are  attempting  to  constrain.  Shortening  the  time  it  takes 
to  make  standards  is  not  necessarily  a good  idea.  Imagine  a world  with  many  easily  and  hastily  constructed 
standards  that  are  ill-conceived  in  their  development. 

Properly  modeling  the  enterprise  will  allow  more  consistent  modularization  so  that  enterprises  can 
ejfectively  plug-and-play  their  processes.  The  models  will  ameliorate  the  need  to  develop  the  entire  system 
at  one  time.  Simulation  will  be  possible  allowing  one  to  evaluate  interoperation  among  interenterprise 
entities  and  to  evaluate  systems  with  differing  granularity.  Enterprises  will  be  able  to  plan  migration  paths 
more  effectively.  Information  should  be  a separate  asset,  so  that  changing  applications  will  be  possible 
without  re-entering  information  about  the  products  and  processes  unnecessarily.  Enterprises  can  define 
paths  using  standards  and  enterprise  models  to  make  the  product  and  process  information  tie  logically  into 
enterprise  goals,  strategies,  capabilities,  and  business  rules.  The  models  and  standards  should  be  scalable  so 
that  a high-level  model  is  essentially  the  same  as  a lower-level  model;  that  is,  they  should  use  the  same  or 
compatible  modeling  constructs  for  all  levels. 

Rather  than  setting  specific  limits  to  everything,  such  a standards  set  should  be  designed  to  force 
enterprises  to  analyze  and  document,  perhaps  electronically  on-line,  what  they  do;  and  then  operate  their 
enterprise  accordingly.  Lower-level  standards  would  still  define  interfaces  and  the  supplying  process  would 
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indicate  which  standards  apply  for  that  particular  communication.  They  would  also  share,  on-line,  the  set  of 
information  they  need  to  know  about  their  processes.  This  way,  an  enterprise  shopping  for  a process  would 
be  able  to  evaluate,  on-line,  that  a process  meets  both  quality  and  integration  guidelines  and  that  they 
conform  to  listed  interface  standards.  The  process  in  the  shopping  enterprise  could  then  make  any  needed 
adjustments  to  itself  and  to  the  appropriate  enterprise  model  (function,  hardware,  software,  communication, 
and  information),  establish  a relationship,  and  operate  in  an  acceptable  (to  both  parties)  level  of  integration. 

Are  there  special  standards  required  to  enable  virtual  enterprises?  A virtual  enterprise,  or  an  extended 
enterprise,  is  an  enterprise—not  really  different  from  a traditional  enterprise  other  than  the  fact  that  it  can 
append  and  shed  processes  quickly.  There  are  more  legal  and  regulatory  issues  than  technical  issues  when 
removing  barriers  to  virtual-enterprise  operations.  Technically  the  standards  categories  involved  are  the 
same:  hardware,  software,  communications,  information,  and  architecture.  The  notion  of  virtual  enterprise 
brings  in  a time  element  such  that  the  enterprise  can  form  or  dissolve  very  quickly.  To  accomplish  this, 
standards  other  than  just  technical  ones  must  be  in  place.  A virtual-enterprise  candidate  may  have  to 
negotiate  such  contracts  as  a basic-ordering  agreement  in  advance  of  considering  such  an  alliance. 
Collaborating  enterprises  must  resolve  other  things  in  a generic  sense  long  before  true  virtual-enterprise 
commerce  can  succeed.  Eventual  parties  comprising  the  enterprise  will  probably  pre-defme  the  following, 
currently  often  locally  unique:  financial  standards,  environmental-impact  standards,  markup  language, 
safety  requirements,  statutes,  product  liability,  quality,  and  organizational  requirements. 

Standardizing  the  enterprises,  parts  of  the  enterprise,  the  products,  the  information  transferred,  and  the 
processes,  is  probably  not  going  to  be  a productive  use  of  standard-making  resources.  What  seems  more 
useful  is  to  standardize  the  interfaces,  the  nomenclature,  and  the  formats  and  allow  the  enterprise-tool 
builders  to  use  these  standards  to  design  software  in  such  a way  as  to  allow  the  processes  to  communicate. 

3 Strategic  Standardization 

What  is  the  best  way  to  employ  standards  in  an  enterprise?  Many  executives  feel  that  funding  standards 
development  is  a non-value-added  activity,  and  that  paying  extra  money  to  have  standards  incorporated  in 
the  tools  they  buy  is  an  increase  in  process  cost.  They  feel  that  both  are  a cost  of  doing  business  and  this 
cost  should  be  minimized  [HOW96].  This  could  be  a valid  course  of  action  for  enterprises  that  plan  to 
maintain  control  of  all  processes  that  produce  their  product,  sell  their  product  locally,  and  face  limited 
competition.  Enterprises  that  plan  to  produce  and  market  their  product  globally  may  take  a different  view. 

For  the  global  enterprise  a better  approach  to  planning  for  standards  may  be  to  include  standardization  as  a 
component  of  their  strategy  [BET95].  These  enterprises  would  be  planning  to  operate  on  a more  global 
basis,  planning  to  compete  more  effectively  in  a new  market,  seeking  to  expand  their  market  or  their 
competitive  position,  and  seeking  ways  to  protect  significant  investment  in  rapidly  changing  technology. 
These  investments  could  be  in  their  manufacturing  facilities,  quality  assurance  and  environmental  impact 
policies  and  procedures,  and  process-interoperability  plans.  The  goal  of  strategic  standardization  is  to  see 
how  certain  standards  would  help  the  enterprise  better  fulfil  its  mission.  One  or  more  of  these  strategies 
could  be  invalid  or  prohibitively  difficult  and  expensive  if,  at  the  same  time,  the  company  did  not 
investigate  ways  to  mitigate  barriers  that  could  impede  success  because  sufficient  attention  was  not  paid  to 
standards.  Analyzing  these  strategies  properly  can  indicate  marketing  opportunities  or  probable  cost  saving. 
Cost  saving  could  come  from  leverage  achieved  through  working  with  others  to  achieve  a shared  advantage 
in  some  area  of  commerce;  either  to  improve  infrastructure,  process  interoperability,  or  the  operation  of 
virtual  (or  extended)  enterprises.  The  marketing  opportunities  would  arise  from  government  or  trading-bloc 
requirements  to  require  quality,  environmental,  and/or  recycling  standards  as  a hurdle-of-entry  into  that 
market. 

In  applying  strategic-standardization  management,  the  standards-investment  decision  becomes  a strategic 
one  for  the  enterprise  rather  than  a tactical  one  for  the  process.  Planners  must  evaluate  what  they  are  trying 
to  accomplish,  which  standards  would  make  the  job  easier,  and  the  best  way  to  get  those  standards 
implemented.  This  would  involve  standards  development  as  well  as  lobbying  to  gain  acceptance.  Strategic- 
standardization  management  is  not  about  standards.  Rather,  it  is  about  leveraging  all  aspects  of  the 
standardizing  process  to  optimize  competitiveness.  This  should  be  a horizontal  discipline,  that  is,  enterprise 
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wide  rather  than  applicable  to  a single  product  or  process.  Example  horizontal  strategies  include  quality, 
environmental,  electronic-data  interchange,  and  safety.  Parallel  with  this  horizontal-enterprise  strategy,  a 
new  category  of  standard  has  emerged— often  referred  to  as  horizontal  standards.  Rather  than  affecting  one 
process  or  tool  these  standards  affect  everything  that  an  enterprise  does  within  the  subject  area  of  the 
standard.  All  of  the  enterprise  processes  and  the  infrastructure  that  supports  them  would  be  affected. 
Therefore  to  position  the  enterprise  to  best  deal  with  the  standard  requires  executive-level  decision  making 
during  the  strategy-making  process  and  not  disjointed  point  solutions.  The  philosophy  of  some  of  these 
horizontal  standards  is  slightly  different  from  the  usual  standards. 

These  standards  tend  to  ask  what  one  does  rather  than  to  tell  everyone  what  to  do.  ISO  9000  series  requires 
that  for  compliance,  one  must  reveal  all  enterprise-quality-related  activities  and  procedures,  document 
them,  implement  them  as  documented,  then  certify  that  it  is  done.  Perhaps  improving  enterprise-process 
interoperability  will  require  a similar  philosophy.  Rather  than  forcing  every  process  that  wishes  to 
communicate  to  have  the  same  everything,  maybe  the  processes  involved  in  the  transaction,  the  querying 
process  and  a responding  process,  could  operate  by  asking  rather  than  telling.  To  do  this,  the  process 
initiating  the  discourse  could  ask  another  process,  in  a standard  way,  what  that  process  speaks,  what  its 
capability  is,  and  whatever  else  is  required.  The  answering  process  would  respond  in  a standard  way.  These 
interactions  could  be  on  a resource  such  as  the  Internet.  The  processes  then  could  determine  between 
themselves  the  best  way  to  communicate. 

Standards  at  the  correct  level  and  constraining  the  correct  things  act  to  preserve  innovation  incentive.  They 
allow  users  to  form  alliances  more  easily  and  with  fewer  barriers,  and  they  allow  more  effective  product 
and  process  differentiation;  that  is,  they  enable  commerce  to  be  effective  and  competitive.  With  more 
deregulation,  companies  are  viewing  standardization  more  globally,  and  at  a strategic  perspective  rather 
than  at  a tactical  perspective.  Without  the  strategic  viewpoint,  standards  can  be  a barrier  to  global 
operations  because  different  markets  have  legally  enforceable  entry  requirements  that  must  be  addressed  at 
the  corporate  or  government  level. 

4 Conclusions 

Cultural  inertia,  direction  and  rate  of  enterprise  change,  and  human  ingenuity  will  limit  the  effectiveness 
and  use  of  standards  to  constrain  enterprise  design.  Defining  and  representing  the  interfaces  that  exist  in  a 
manner  similar  to  the  ISO  9000  series  of  standards  may  enable  enterprises  to  communicate  without 
standardizing  an  enterprise  or  process  structure.  The  process  of  evaluating  how  best  to  communicate 
electronically  will  involve  some  tradeoffs.  Enterprise  designers  must  evaluate  whether  the  technology  used 
to  achieve  acceptable  functionality  has  a life  that  is  shorter  than  the  time  it  takes  to  develop  and/or  modify  a 
standard  to  constrain  the  technology.  The  alternative  to  standards  is  to  use  the  technology  to  circumvent  the 
problem. 

There  are  several  areas  to  evaluate  when  analyzing  enterprise  operation.  If  sets  of  models  from  one 
enterprise  are  to  connect  to  models  of  another  enterprise,  both  sets  of  models  must  have  considered  the 
same  areas  or  the  models  probably  will  not  interoperate.  To  ascertain  whether  modelers  can  manage  these 
areas  consistently,  informally  from  a checklist  or  formally  by  standards,  needs  further  implementation 
experience  and  discussion  to  decide.  The  issue  needs  satisfactory  resolution  because  the  areas  in  question 
are  precisely  the  interfaces  that  one  enterprise  will  mediate  with  another  to  communicate. 

Areas  of  integration  technology  needing  standards-like  attention  are  hardware,  software,  communications 
protocols,  information,  and  architectures.  Enterprise-representation  technology,  coordinated  terminology, 
and  enterprise-representation  architectures  are  not  yet  adequately  addressed.  There  are  a few  areas  that 
appear  to  be  good  candidates  for  standards.  One  is  terminology  and  another  is  enterprise  models.  The 
solution  to  the  terminology  problem  appears  to  lie  in  some  registry  to  which  an  individual  enterprise  can 
map  its  terminology.  Properly  constraining  enterprise  models  and  the  way  they  communicate  among 
themselves,  would  reveal,  in  a standard  way,  the  necessary  points  from  which  one  enterprise  architecture 
can  mediate  an  information  transfer  with  another  enterprise  architecture. 
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Ensuing  enterprise  representation  standards  should  not  mandate  standard  processes,  standard  enterprises, 
standard  organizations,  standard  methodologies,  or  standard-enterprise  data.  Enterprise-representation 
standards  should  defme  the  key  ideas  involved  with  enterprise  frameworks  or  enterprise  models  so  that  the 
models  produced  are  consistent.  Then,  vendors  can  develop  tools  that  produce  and  operate  frameworks  and 
models  with  minimum  investment  risk  and  with  the  maximum  confidence  that  they  will  encounter  known 
interfaces.  Ideally,  standards  should  enable  interoperability  and  still  protect  innovation,  efficiency  of 
approach,  and  migration  capability. 

Interprocess  communication  may  not  be  100%.  Well,  it  rarely  ever  was,  is  not  now,  and  maybe  never  will 
be  the  case  that  everyone  will  be  invested  to  the  same  level  and  version  to  enable  1 00%  communication  on 
the  first  try.  Let  us  recognize  that  fact  and  fmd  a way  to  communicate  to  the  best  of  our  ability.  It  may 
require  a change  in  standardization  philosophy  to  move  toward  ask  rather  than  tell  standards. 

Governments  around  the  world  use  standards  in  a strategic  sense;  for  example,  as  a barrier  to  product  entry. 
A corresponding  strategic  view  will  help  companies  to  operate  better  in  global  environments.  Businesses 
must  pay  closer  attention  to  standards  matters  to  insure  that  they  will  be  able  to  compete  on  a playing  field 
that  is  more  level.  Many  standards  issues  are  becoming  more  company  or  industry  wide,  such  as  quality, 
environmental,  services,  and  electronic-data  interchange.  Continued  participation  in  standards  activities  and 
strategic  treatment  are  needed  to  avoid  standards  that  add  cost  but  do  not  add  value,  and  to  avoid  standards 
that  are  being  developed  deliberately  for  the  purpose  of  restraining  trade. 
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